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Application Overview 

BOMP is a multi-level Bill Processor and one of the key elements to a successful manufacturing sys¬ 
tem. It includes the following capabilities: 

• Allows full Product Structure maintenance. 

• Allows user-assigned sequence of components. 

• Components’ attaching operation can be specified. 

• Quantity per parent is supported to 4 decimals. 

• Scrap/shrinkage can be specified. 

• Obsolete Bills are supported. 

• Forecasted/planning Bills are supported. 

• Modular Bills are supported. 

• Allows fast sort of the Product Structure file. 

• Provides for user-controlled Product Structure file reorganization. 

• Prints/Displays Single Level Bill of Materials report. 

• Prints/Displays Single Level Where-Used report. 

• Prints/Displays Indented Bill of Materials report. 

• Prints/Displays Indented Where-Used report. 

• Prints/Displays Summarized Bill of Materials report. 

• Interfaces to six other MCBA application packages. 

• Security System and multi-company capabilities are supported. 


Application Details 


Product Structure Maintenance 

On-line Product Structure file maintenance is provided 
allowing: add, change, inquire and delete. The product 
structure record includes: 

• Parent Item Number (15 alphanumeric charac¬ 
ters. 

• Sequence number of component within this struc¬ 
ture 

•Component Item Number (15 alphanumeric 
characters) 

• Quantity-Per (7 numeric characters including 4 
decimals) 

• Operation where component attaches to parent 

• Scrap/Shrinkage Factor 

• Parents’ address in the Item Master File 

• Components' address in the Item Master file 

• User field (6 numeric characters—could be a 
date) 

The Component Item Number is not part of the sort on 


the Product Structure file so components will appear in 
the order they were entered on inquiries/reports. Flow- 
ever if some other component sequence is desired it can 
be handled via the sequence number. 

One of the important considerations of the capability to 
specify the operation (where each component is used) is 
that the user can now see if any of his shortages are in 
fact not required until later on in the routing. This capabili¬ 
ty is used by MCBA’s Shop Floor Control (SFC). It is also a 
consideration when costing scrapped assemblies. 

The ability to specify how much each component shrinks 
or is scrapped, on average, gives the user the capability 
of being more accurate in estimating component usage. 
MRP, SFC and Product Costing will be able to more 
closely determine the correct component usage re¬ 
quired. 

Cbsolete structures can be so noted. This allows the user 
to specify structures he doesn’t want to use now but, for 
whatever reason, does not want to delete. Fie can leave 
them on file to be reviewed later to then determine if they 
should be modified or deleted. 




Forecasted bills (planning bills) are an artificial grouping 
of items, in bill of material format, used to facilitate 
master scheduling and/or material planning. For exam¬ 
ple, forecasted bills can be used in MRP’s master sched¬ 
uling to explode requirements properly for optional 
components. 

Modular bills are a type of planning bill which is arranged 
in product modules or options. Often used in companies 
where the product has many optional features; e.g. auto¬ 
mobiles. The key to this function is the capability to 
specify a negative quantity-per (which is supported). 

Sort Product Structure File 

There are two ways to sort the Product Structure (P/S) 
File; directly with the specified sort function; or indirectly 
as a part of the slower but more functional reorganiza¬ 
tion. The P/S sort is fast and required in order for newly 
added components to be correctly sequenced on inqui¬ 
ries/reports. 

This is a good example of MCBA’s keep-it-simple ap¬ 
proach. It makes the system more understandable and 
useful. Multiple chaining back and forth can be disas¬ 
trous if any problems develop. To ensure the security of 
correct chaining, cumbersome chain validation code is 
usually written. MCBA’s P/S file just chains directly back 
to parent and component parts, thus saving overhead. 
The only other P/S chains are in a small, separate file 
which shows components with their addresses of P/S 
records where used. Even if every chaining address 
were somehow wiped out of the P/S File, they could all be 
re-built by the function described herein. 

Product Structure Reorganization 

The P/S reorganization is a menu driven function. Nor¬ 
mally MCBA programs automatically reorganize files 
containing fifty or more records flagged for deletion. 
However, it is worth noting that that is not the case here, 
as more user-control is appropriate. 

The reorganization is needed to sort the P/S file, remove 
deleted records and re-establish the components where- 
used file. 

Single Level Bill Inquiry 

Designed for a video display, the Single Level Bill inquiry 
shows all the components for a parent (specified at run¬ 
time) on the next level down for that parent. If the screen 
cannot contain all these components the user is allowed 
to page through all remaining components. 

Single Level Bill of Materials 

Designed as a printed report, the Single Level Bill of 
Materials (VTIOOs only) program offers the user a run¬ 
time option to display the report instead of printing it. The 
report format contains more data than the inquiry above. 

If displayed, the 132 column screen format is condensed 
onto the VTIOO and is automatically scrolled. Since the 


single level bill is the most popular format in actual 
usage, it is provided with the most accesses for the user. 
Like the inquiry above, but with more data per compo¬ 
nent, this report format shows all parent components one 
level down from that parent item. One, few or all parent 
items may be selected at run-time for this report. 

Single Level Where-Used 

The Single Level Where-Used program does just the 
reverse of the single level bill. Here, for a given compo¬ 
nent, all its parents one level above are shown. The 
Single Level Where-Used is designed as a printed report 
but may be printed or displayed (in the 132 column for¬ 
mat) at the discretion of the user at run-time. One, few or 
all component items may be selected at run-time for this 
report. One common use of this is when a component is 
to be replaced by some other component. This report 
can be run to show all the to-be-replaced components’ 
direct parents. 

Indented Bill of Materials 

Designed as a printed report, the Indented Bill of 
Materials (VTIOOs only) program offers the user a run¬ 
time option to display the report instead of printing it. If 
displayed, the 132 column format is condensed onto the 
VTIOO and is automatically scrolled. 

The Indented Bill of Materials shows all components of a 
specified parent. It is called indented because the output 
actually indents the component item number for each 
level as it goes down the structure. The entire structure 
for each specified parent item is output as it is. For exam¬ 
ple, if one component is used in four different parts of the 
structure, it appears on the report four times at the ap¬ 
propriate places in the structure. One, few or all parent 
items may be selected at run-time for this report. Some 
uses of this report are: 1) to see the entire product struc¬ 
ture for a parent, and; 2) to see all the raw materials/ 
purchased parts used for the parent. The act of execut¬ 
ing the indented bill is sometimes referred to as an 
“explosion” of a parent’s components, as it seems to ex¬ 
plode or expand outwardly. 

Indented Where-Used 

The Indented Where-Used program does just the reverse 
of the indented bill. Here, for a given component, all its 
parents are shown. The Indented Where-Used is de¬ 
signed as a printed report and may be printed but may 
also be displayed at the discretion of the user at run-time. 
It is called indented because the output is indented by 
level all the way up to the end item. One, few or all com¬ 
ponent items may be selected at run-time for this report. 
One use of this report is to identify all parent items (par¬ 
ticularly end-items) that may be affected by a change or 
replacement of a component. The act of executing the 
indented where-used is sometimes referred to as an 
“implosion” of a component’s parents. Tracing up a 
structure is like closing in on the end-item, i.e. the struc¬ 
ture gets smaller as you get closer to the top. 


Summarized Bill of Materials 

Designed as a printed report, the Summarized Bill of 
Materials (VTIOOs oniy) program offers the user a run¬ 
time option to display the report instead of printing it. If 
displayed, the 132 column format is condensed onto the 
VT100 and is automatically scrolled. 

The summarized bill shows all the components of a 
specified parent. It is called summarized because each 
component is shown only once summarized by quantity- 
required (per this parent) at the lowest level the compo¬ 
nent appears in the parent’s structure. This is the clas¬ 
sical parts list in that each part is listed once along with 
total quantity-required to make one parent. One, few or 
all parent items may be selected at run-time for this 
report. 

interfaces to Six Other MCBA Appiication Packages 

• Inventory Management (I/M) 

• Customer Order Processing (COP) 

• Shop Floor Control (SFC) 

• Standard Product Costing (SPC) 

• Base Material Requirements Planning (BMRP) 

• Full Material Requirements Planning (FMRP) 

I/M is the only prerequisite for BOMP; as BOMP carries 
no descriptions or other item master data. 

COP uses BOMP to explode any line-item that is non- 
stocked and allocates its stocked components at the first 


level they appear. COP’S picking list in this case can be 
used as a final assembly order. I/M, BOMP & COP are de¬ 
signed to work very well together. 

SFC can copy bills from BOMP for its Master Bill File. 
SPC needs BOMP’s structure file in order to do the elab¬ 
orate things it does in standard costing products. MRP 
requires BOMP’s structure file in order to know what 
components are required for the gross requirements 
MRP gets from the master schedule. Both Base & Full 
MRP need this function. 

Security 

The security system allows up to 200 passwords and pro¬ 
vides access restrictions to the file level and the applica¬ 
tion level by company. 

Multiple Companies 

Multiple Company support is provided with up to eight (8) 
companies supported. Most users do not have that many 
but they still find this feature very useful for test files 
and/or for operator training. 

Record Size 

Product Structure . 64 characters 

Run-Time Size 

Approximate disk space requirements for BOMP run¬ 
time/object modules is 233KB. 
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